The Devver Blog

A Boulder startup improving the way developers work.

Lessons Learned

As we’ve begun to wrap things up here at Devver, we’ve had the chance to reflect a bit on our experience. Although shutting down is not the outcome we wanted, it’s clear to both Dan and I that doing a startup has been an amazing learning experience. While we still have a lot to learn, we wanted to share some of the most important lessons we’ve learned during this time.

The community

When we started Devver, we were hesitant to ask for feedback and help. We quickly found that people are incredibly helpful and generous with their time. Users were willing to take a chance and use our products while giving us valuable feedback. Fellow Rubyists gave us ideas and helped us with technical problems. Mentors made time for meetings and introduced us to others who could assist us. And other entrepreneurs, both new and seasoned, were happy to share stories, compare experiences, and offer support.

If you are working on a startup, don’t be afraid to ask for help! The vast majority of people want to help you succeed, provided that you respect them and their time. That means you need to prepare adequately (do your research and ask good questions), figure out their preferred methods of communication (e.g. don’t call if they prefer email), show up on time, don’t overburden them, and thank them. And when other people need your help, give back!

You can build awesome relationships with various communities on your own, but we strongly recommend joining a mentorship program like TechStars. The program accelerated the process of connecting with mentors, users, and other entrepreneurs by providing an amazing community during the summer (and to this day). The advice, introductions, and support have been simply incredible.

Founding team

Dan and I are both technical founders. Looking back, it would have been to our advantage to have a third founder who really loved the business aspect of running a startup.

There is a belief (among technical founders) that technical founders are sufficient for a successful startup. Or, put more harshly, that you can teach a hacker business, but you can’t teach a businessman how to hack“. I don’t want to argue whether that’s true or not. Clearly there are examples of technical founders being sufficient to get a company going, but my point is that having solely technical founders is non-optimal. You can teach a hacker business, but you can’t make him or her get excited about it, which means it may not get the time or attention it deserves.

Hackers are passionate about, well, hacking. And so we tend to measure progress in terms of features completed or lines of code written. Clearly, code needs to be written, but ideally a startup would have a founder who is working on important non-technical tasks: talking with customers, measuring key metrics, developing distribution channels, etc. I’m not advocating that only one founder works on these tasks while technical founders ignore customer development – everyone needs to get involved. Rather, I’m pointing out that given a choice, technical founders will tend to solve problems technically and having a founder who has the opposite default is valuable.

Remote teams

We embraced working remotely: we hired Avdi to work in Pennsylvania while Dan and I lived in Boulder and later on, Dan moved to Washington, DC. There are many benefits to having a distributed team, but two stood out in our experience. First, we could hire top talent without having to worry about location (in fact, our flexibility regarding location was very attractive to most candidates we interviewed). Secondly, being in different locations allowed every team member to work with minimal distractions, which is invaluable when it comes to efficiently writing good code.

That said, communication was a challenge. To ensure we were all synced up, we had a daily standup as well as a weekly review. When Dan moved to DC, he and I scheduled another weekly meeting with no set agenda to just bring up all the issues, large and small, that were on our minds. We also all got together in the same location every few months to work in the same room and rekindle our team energy.

Also, pair programming was difficult to do remotely and we never came up with a great solution. As a result, we spent less than a day pairing a week on average.

The most significant drawback to a remote team is the administrative hassle. It’s a pain to manage payroll, unemployment, insurance, etc in one state. It’s a freaking nightmare to manage in three states (well, two states and a district), even though we paid a payroll service to take care of it. Apparently, once your startup gets larger, there are companies that will manage this with minimal hassle, but for a small team, it was a major annoyance and distraction.

Product development

Most of the mistakes we made developing our test accelerator and, later, Caliper boiled down to one thing: we should have focused more on customer development and finding a minimum viable product (MVP).

The first thing we worked on was our Ruby test accelerator. At the time, we thought we had found our MVP: we had made encouraging technical progress and we had talked to several potential customers who were excited about the product we were building. Anything simpler seems “too simple” to be interesting.

Our mistake at that point was to go “heads down” and focus on building the accelerator while minimizing our contact with users and customers (after all, we knew how great it was and time spent talking to customers was time we could be hacking!). We should have asking, “Is there an even simpler version of this product that we can deliver sooner to learn more about pricing, market size, and technical challenges?”

If we had done so, we would have discovered:

  • whether the need was great enough (and if the solution was good enough) to convince people to open their wallets
  • that while a few users acutely felt the pain of slow tests, most didn’t care about acceleration. However, many of those users did want a “simpler” application – non-accelerated Ruby cloud testing.
  • the primary technical challenge was not accelerating tests, it was configuring servers for customers’ Rails applications. Not only did we spend time focusing on the wrong technical challenges, we also made architectural decisions that actually made it harder to solve this core problem.

After eventually discovering that setup and configuration was our primary adoption problem (and after trying and failing to implement various strategies to make it simple and easy), we tried to move to the other end of the spectrum. Caliper was designed to provide value with zero setup or configuration – users just provided a link to source code and instantly got valuable data.

Unfortunately, we again made the mistake of focusing on engineering first and customer development second. We released our first version to some moderate success and then proceeded to continue to churn out features without really understanding customer needs. Only later on, after finally engaging potential customers did we realize that market was too small and price point was to low to have Caliper sustain our company by itself.

Conclusion

This is by no means a comprehensive list, but it is our hope that other startups and founders-to-be can learn from our experiences, both mistakes and successes. Doing a startup has been an incredible learning experience for both Dan and I and we look forward to learning more in the future – both first-hand and from the amazing group of entrepreneurs and hackers that we’ve been privileged enough to know.

Written by Ben

April 26, 2010 at 11:04 am

45 Responses

Subscribe to comments with RSS.

  1. […] This post was mentioned on Twitter by devver, skim. skim said: RT @devver: New post: Lessons learned http://devver.net/blog/2010/04/lessons-learned/ […]

  2. So sorry guys. failing like this really sucks. however, i have come out of the eventvue failure with even more determination to "make new mistakes". hope you guys get that energy again soon.

    Rob

    April 26, 2010 at 6:52 pm

  3. hey fellow TechStar alumns. It's a tough decision to close up shop but I have a feeling we'll be hearing more from you guys really soon. Keep us all posted! We're rooting for you

    Stephen Wooten

    April 26, 2010 at 7:13 pm

  4. Social comments and analytics for this post…

    This post was mentioned on Twitter by devver: New post: Lessons learned http://devver.net/blog/2010/04/lessons-learned/

  5. Good insights all around. I agree about the challenges of a distributed team when it comes to payroll, what size company does it start to make sense to use one of those 'other agencies' that you mentioned?

    Justin Smestad

    April 26, 2010 at 7:32 pm

  6. Very sound advice. Especially interesting to see your thoughts on technical founders. I'm a marketing/vision kind of guy. I can lay the groundwork for technology, but I can't make the tech side of it all work.

    That's where I'm hung up in my own ambitions. Business guys like myself can't make a startup with the tech people, and it's interesting to see that acknowledged on your end.

    The skill sets are mutually exclusive. Tech people can create and ideate great feature sets, but it's the marketing/biz guy that can analyze the market opportunity and measure the benefits a service offers. After all, it's all about benefits, not features.

    Brandthony

    April 26, 2010 at 8:01 pm

    • I meant "can't make a startup WITHOUT the tech people."

      Brandthony

      April 26, 2010 at 8:04 pm

  7. Thank you for sharing your insights Ben, especially on the challenges of a remote team and MVP focus. On another note, thanks again for participating in David's SpeakSake. Looking forward to hearing about your next project.

    Stephanie

    April 26, 2010 at 8:38 pm

  8. Thanks for sharing, gotta be odd to be taking such an introspective look at the situation right now. Good luck to you both.

    Al Doan

    April 26, 2010 at 8:42 pm

  9. Great post, thanks for sharing

    Mike Lewis

    April 26, 2010 at 9:10 pm

  10. As thoughtful as this post is, it shows that you will land on your feet for sure. Thanks very much for posting.

    Scott Yates

    April 26, 2010 at 9:11 pm

  11. Ben, you and Dan are two of my favorite nerds! Im proud to have watch your growth and your continued success…and, of course, anything I can do (including convince you to come work with comic books…hint, hint…) let me know!

    micah

    April 26, 2010 at 9:14 pm

    • Haha thanks for that Micah. I am following with interest your companies moves. I am looking forward to the IPhone app. Thanks for your support and advice.

      danmayer

      April 26, 2010 at 9:38 pm

  12. Thanks everyone for the well wishes and support. We learned a lot from the experience, and hopefully our experience can help others.

    danmayer

    April 26, 2010 at 9:36 pm

  13. thanks for posting – very admirable considering the sting of the event – IMHO, this really indicates that entrepreneurship is right for you, that you are reflective and can appreciate the experience for the lesson learned, as well as share it – good luck in your next venture

    angela

    April 26, 2010 at 10:45 pm

  14. Fellas, thanks for sharing – it's definitely helpful for other startups to distill lessons like these and reinforce them. I'm sure you'll incorporate what you learned into your next endeavor and you'll be stronger for it.

    By chance are you guys going to be at Boulder.me? Myself and another local AZ startup guy are trekking up there next week – maybe we can buy you a beer?

    Sean

    Sean Tierney

    April 26, 2010 at 11:04 pm

    • I'll be in town and I'm happy to meet up for a beer. Ping me before you head up to figure out a time/place. See you soon!

      Ben Brinckerhoff

      April 26, 2010 at 11:11 pm

  15. Thanks everyone for the words of support. We appreciate it.

    Ben Brinckerhoff

    April 26, 2010 at 11:11 pm

  16. Can you elaborate on how you discovered that the market wasn’t large enough to support caliper? Did you ask beta testers what the were willing to pay & then extrapolate that to the estimated number of users (how did you find that number?) and then you realized it wouldn’t be enough $ to survive, or was it not enough money to get bought by someone paying millions? What was your original goal for $, and how did that change over time, ie did it start at millions and go down as you got desperate for customers, or were you more conservative at the start? Did you use any methodology when writing your vision, building the product, testing with potential users, pivoting, etc, or did you make it up as you went along? Lots of questions, please keep blogging thanks

    Steve

    April 27, 2010 at 5:47 am

    • I probably won't get into details of everything. On the Caliper project we starte signing up private beta users and discussing price with them. We quickly learned that what they were willing to pay for the service couldn't sustain a company on it's own. It could be used to help up sell other products or services (consulting). When looking at what people would pay and the expected number of paying customers over time, it just didn't make sense to continue with the product as the primary goal of a funded company.

      danmayer

      April 27, 2010 at 6:24 pm

  17. Stellar post, all the best with the next one =)

    Adam Ayers

    April 27, 2010 at 11:13 pm

  18. Really great advice… I think developers get caught up with developing the best product and forget that the best product is defined by the product customers want most, and not by the beauty of code.

    Sean Coleman

    April 27, 2010 at 11:52 pm

  19. Great advice. Good luck next time. Best.

    @criativo

    April 28, 2010 at 2:43 am

  20. Thank you some interesting lessons learnt. Have been considering a remote team, this helped me

    steve

    April 27, 2010 at 8:45 pm

  21. […] I came across a few very interesting set of “lessons learnt from my start-up” articles. (thanks Mathieu, Joel for the references) : […]

  22. Thank you Ben (& Dan) for taking the time to dissect and analyze your experience with Devver.
    What really impressed me the most is when you say "we should have focused more on customer development and finding a minimum viable product (MVP) . . . ", that is probably the most critical piece in any startup or any project, what is the next logical step?
    Best! Lor3nzo

    lor3nzo

    April 29, 2010 at 5:37 pm

  23. Customer development is an ongoing process. Once you've identified an MVP (which is an iterative process itself), the next step is to keep iterating as you add or improve features. Measure how the product is performing along key metrics, talk to customers, merge customer feedback with your vision, build and improve features, and then do it all over again!

    Ben Brinckerhoff

    April 29, 2010 at 6:10 pm

  24. Hey, anything that does not kill you, only makes you stronger! Good luck guys and I am sure you will bounce back again!

    Ashok Srinivasan

    April 29, 2010 at 9:44 pm

  25. […] Lessons Learned on Running a Startup – Fellow Boulder startup Devver recently decided to shut down and shared their lessons on what worked and didn’t work. Really honest insights from a brilliant founder, and a great read for all SMB entrepreneurs. […]

  26. […] one of co-founders, Ben Brinckerhoff, points out: Most of the mistakes we made developing our test accelerator and, later, Caliper boiled down to […]

  27. Understanding this stuff can be super annoying, thanks for typing this article to clear up some confusion.

    Auditing

    May 2, 2010 at 9:07 pm

  28. Ben, I don’t have your email but my buddy and I are in town from Phx for the startup week events and are bouncing around co-working out of various places and hitting the night time events. hit me up if you wanna grab coffee or a beer – 480.221.5500

    sean

    Sean Tierney

    May 5, 2010 at 4:16 pm

    • Sean – yeah, I’ll be around. Shoot me an email and we’ll figure out a time (ben@devver.net)

      Ben Brinckerhoff

      May 5, 2010 at 7:10 pm

  29. […] the context, even though they meant well and are intelligent folks. Post-Mortem Title:  Lessons Learned Company:  Devver The most significant drawback to a remote team is the administrative hassle. […]

  30. […] understand the context, even though they meant well and are intelligent folks. Post-Mortem Title: Lessons Learned Company: Devver The most significant drawback to a remote team is the administrative hassle. […]

  31. […] need a programmer, and if you’re the right fit a programmer will also need you. In a post-mortem about the failure of devver, the founders wrote “Dan and I are both technical founders. Looking back, it would have been to […]

  32. […] 3. This post mortem provides a good breakdown of how the loss of focus on the parts of the ‘company’ structure lead to failure (could be more comprehensive in my opinion) The Devver Blog: Lessons Learned […]

  33. […] or build product but who didn’t relish the idea of promoting the product.  The folks at Devver highlighted the need to find someone who enjoys creating and finding distribution channels and developing […]

  34. […] or build product but who didn’t relish the idea of promoting the product.  The folks at Devver highlighted the need to find someone who enjoys creating and finding distribution channels and developing […]

  35. Good, honest post. Thank you for taking time to teach the rest of us and I hope you guys have luck with whatever you do next!

    Dave

    March 2, 2011 at 11:59 pm

  36. […] did Devver fail?   Avdi Grimm, Rubyist since 2001; using Rails profe… Here a go: https://devver.wordpress.com/2010…8:10amView All 0 CommentsCannot add comment at this time. Add […]

  37. […] тяга к продвижению продукта. Ребята в проекте Devver подчеркнули крайнюю важность заполучить кого-нибудь, кто любит […]

  38. […] 3. https://devver.wordpress.com/2010/04/26/lessons-learned/ […]

    Startup postmortems : Seyi

    November 20, 2012 at 4:59 pm

  39. […] worry if you haven’t. Devver crashed and burned in 2010 after two years in operation. Co-founder Ben Brinckerhoff blames the failure partly on their hesitation to get feedback from their customers. The focus was on the […]


Comments are closed.